IRIX Base Documentation 2001 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / share / catman / a_man / cat1 / gated.z / gated

Wrap

Text File | 1998-10-20 | 61.1 KB | 1,057 lines

GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) NNNNAAAAMMMMEEEE gated - gateway routing daemon SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS ////uuuussssrrrr////eeeettttcccc////ggggaaaatttteeeedddd [ ----tttt[iiiieeeerrrrppppuuuuRRRRHHHH] ] [ logfile ] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _G_a_t_e_d is a routing daemon that handles multiple routing protocols and replaces _r_o_u_t_e_d(1M), _e_g_p_u_p(1M), and any routing daemon that speaks the HELLO routing protocol. _G_a_t_e_d currently handles the RIP, EGP, and HELLO routing protocols. _G_a_t_e_d can be configured to perform all routing protocols or any combination of the three. The configuration for _g_a_t_e_d is stored in the file /_u_s_r/_e_t_c/_g_a_t_e_d._c_o_n_f. CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE TTTTRRRRAAAACCCCIIIINNNNGGGG OOOOPPPPTTTTIIIIOOOONNNNSSSS _G_a_t_e_d can be invoked with a number of tracing flags and/or a log file. Tracing flags may also be specified in the configuration file with the ``traceflags'' clause. _G_a_t_e_d forks and detaches itself from the controlling terminal unless tracing flags are specified without specifying a log file, in which case all tracing output is sent to the controlling terminal. The valid tracing flags are as follows: ----tttt If used alone, log all error messages, route changes and EGP packets sent and received. Using this flag alone turns on the iiii, eeee, rrrr, and pppp trace flags automatically. When used with another flag, the ----tttt has no effect and only the accompanying flags are recognized. Note that when using other flags, ----tttt must be used with them. iiii Log all internal errors and interior routing errors. eeee Log all external errors due to EGP, exterior routing errors, and EGP state changes. rrrr Log all routing changes. pppp Trace all EGP packets sent and received. uuuu When used with p, R, H or N, display the entire contents of routing packets sent and received. RRRR Trace all RIP packets sent or received. HHHH Trace all HELLO packets sent or received. NNNN Trace all SNMP transactions. _G_a_t_e_d always logs fatal errors. If no log file is specified and no tracing flags are set, all messages are sent to /_d_e_v/_n_u_l_l. PPPPaaaaggggeeee 1111 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) SIGNAL PROCESSING _G_a_t_e_d catches a number of signals and performs specific actions. Currently _g_a_t_e_d does special processing with the SIGHUP, SIGINT and SIGUSR1 signals. When a SIGHUP is sent to _g_a_t_e_d and _g_a_t_e_d is invoked with trace flags and a log file, tracing is toggled off and the log file is closed. At this point the log file may be moved or removed. The next SIGHUP to _g_a_t_e_d will toggle the tracing on. _G_a_t_e_d reads the configuration file and sets the tracing flags to those specified with the ``traceflags'' clause. If no ``traceflags'' clause is specified tracing is resumed using the trace flags specified on the command line. The log file specified in the command line is created if necessary and the trace output is sent to that file. The trace output is appended to an already existing log file. This is useful for having rotating log files like those of the _s_y_s_l_o_g(1M) daemon. Sending _g_a_t_e_d a SIGINT will cause a memory dump to be scheduled within the next sixty seconds. The memory dump will be written to the file /_u_s_r/_t_m_p/_g_a_t_e_d__d_u_m_p. _G_a_t_e_d will finish processing pending routing updates before performing the memory dump. The memory dump contains a snapshot of the current _g_a_t_e_d status, including the interface configurations, EGP neighbor status and the routing tables. If the file /_u_s_r/_t_m_p/_g_a_t_e_d__d_u_m_p already exists, the memory dump will be appended to the existing file. On receipt of a SIGUSR1, _g_a_t_e_d will reread selected information from the configuration file. This information currently includes the ``announcetoAS'', ``noannouncetoAS'' and ``validAS''. If no errors are detected the new configuration information is put into effect, if errors are detected, the configuration information is not changed. _G_a_t_e_d will also check the interface status on receipt of a SIGUSR1. CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE OOOOPPPPTTTTIIIIOOOONNNNSSSS FFFFOOOORRRR CCCCOOOONNNNTTTTRRRROOOOLLLLLLLLIIIINNNNGGGG TTTTRRRRAAAACCCCIIIINNNNGGGG OOOOUUUUTTTTPPPPUUUUTTTT ttttrrrraaaacccceeeeffffllllaaaaggggssss ttttrrrraaaacccceeeeffffllllaaaagggg [[[[ttttrrrraaaacccceeeeffffllllaaaagggg]]]] [[[[ttttrrrraaaacccceeeeffffllllaaaagggg]]]] ............ The clause tells the _g_a_t_e_d process what level of tracing output is desired. This option is read during _g_a_t_e_d initialization and whenever _g_a_t_e_d receives a SIGHUP. This option is overridden at initialization time if tracing flags are specified on the command line. The valid tracing flags are as follows: iiiinnnntttteeeerrrrnnnnaaaallll Log all internal errors and interior routing errors. eeeexxxxtttteeeerrrrnnnnaaaallll Log all external errors due to EGP, exterior routing errors, and EGP state changes. rrrroooouuuutttteeee Log all routing changes. eeeeggggpppp Trace all EGP packets sent and received. PPPPaaaaggggeeee 2222 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) uuuuppppddddaaaatttteeee When used with egp, rip, hello or snmp, display the contents of all routing packets sent and received. rrrriiiipppp Trace all RIP packets sent and received. hhhheeeelllllllloooo Trace all HELLO packets sent and received. iiiiccccmmmmpppp Trace all ICMP redirect packets received. ssssnnnnmmmmpppp Trace all SNMP transactions. ssssttttaaaammmmpppp Print a timestamp to the log file every 10 minutes. ggggeeeennnneeeerrrraaaallll A combination of ``internal'', ``external'', ``route'' and ``egp''. aaaallllllll Enable all of the above tracing flags. If more than one ``traceflags'' clause is used, the tracing flags accumulate. DDDDEEEEFFFFAAAAUUUULLLLTTTT CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN _G_a_t_e_d normally reads configuration information from /_u_s_r/_e_t_c/_g_a_t_e_d._c_o_n_f. If this file does not exist, _g_a_t_e_d assumes a default configuration file of: RRRRIIIIPPPP yyyyeeeessss HHHHEEEELLLLLLLLOOOO nnnnoooo EEEEGGGGPPPP nnnnoooo In addition, if the configuration file does not exist, there is only one network interface, and a default route is installed in the kernel, _g_a_t_e_d will exit assuming that a simple default route is adequate. CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE OOOOPPPPTTTTIIIIOOOONNNNSSSS FFFFOOOORRRR HHHHAAAANNNNDDDDLLLLIIIINNNNGGGG RRRROOOOUUUUTTTTIIIINNNNGGGG PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLLSSSS In this section, the numerous configuration options are explained. Each time the _g_a_t_e_d process is started, it reads the file /_u_s_r/_e_t_c/_g_a_t_e_d._c_o_n_f _t_o obtain its instructions on how routing will be managed with respect to each protocol. The configuration options are as follows: RRRRIIIIPPPP {{{{yyyyeeeessss |||| nnnnoooo |||| ssssuuuupppppppplllliiiieeeerrrr |||| ppppooooiiiinnnnttttooooppppooooiiiinnnntttt |||| qqqquuuuiiiieeeetttt |||| ggggaaaatttteeeewwwwaaaayyyy ####}}}} This tells the _g_a_t_e_d process how to perform the RIP routing protocol. Only one of the above RIP arguments is allowed after the keyword ``RIP''. If more than one is specified, only the first one is recognized. A list of the arguments to the RIP clause follows: yyyyeeeessss Perform the RIP protocol. Process all incoming RIP packets and supply RIP information every thirty seconds only if there are two or more network interfaces. PPPPaaaaggggeeee 3333 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) nnnnoooo Do not perform the RIP protocol. Do not perform RIP. ssssuuuupppppppplllliiiieeeerrrr Perform the RIP protocol. Process all incoming RIP packets and force the supplying of RIP information every thirty seconds no matter how many network interfaces are present. ppppooooiiiinnnnttttooooppppooooiiiinnnntttt Perform the RIP protocol. Process all incoming RIP packets and force the supplying of RIP information every thirty seconds no matter how many network interfaces are present. When this argument is specified, RIP information will not be sent out in a broadcast packet. The RIP information will be sent directly to the gateways listed in the ``sourceripgateways'' option described below. qqqquuuuiiiieeeetttt Process all incoming RIP packets, but do not supply any RIP information no matter how many network interfaces are present. ggggaaaatttteeeewwwwaaaayyyy # Process all incoming RIP packets, supply RIP information every thirty seconds, and announce the default route (0.0.0.0) with a metric of #. The metric should be specified in a value that represents a RIP hopcount. With this option set, all other default routes coming from other RIP gateways will be ignored. The default route is only announced when actively peering with at least one EGP neighbor and therefore should only be used when EGP is used. If no ``RIP'' clause is specified, RIP will not be performed. HHHHEEEELLLLLLLLOOOO {{{{yyyyeeeessss |||| nnnnoooo |||| ssssuuuupppppppplllliiiieeeerrrr |||| ppppooooiiiinnnnttttooooppppooooiiiinnnntttt |||| qqqquuuuiiiieeeetttt|||| ggggaaaatttteeeewwwwaaaayyyy ####}}}} This tells _g_a_t_e_d how to perform the HELLO routing protocol. The arguments parallel the RIP arguments, but do have some minor differences. Only one of the above HELLO arguments is allowed after the keyword ``HELLO''. If more than one is specified, only the first one is recognized. A list of the arguments to the HELLO clause follows: yyyyeeeessss Perform the HELLO protocol. Process all incoming HELLO packets and supply HELLO information every fifteen seconds only if there are two or more network interfaces. nnnnoooo Do not perform the HELLO protocol. Do not perform HELLO. ssssuuuupppppppplllliiiieeeerrrr Perform the HELLO protocol. Process all incoming HELLO packets and force the supplying of HELLO information every fifteen seconds no matter how many network interfaces are present. ppppooooiiiinnnnttttooooppppooooiiiinnnntttt Perform the HELLO protocol. Process all incoming HELLO packets and force the supplying of HELLO information every fifteen seconds no matter how many network interfaces are present. When this argument is specified, HELLO PPPPaaaaggggeeee 4444 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) information will not be sent out in a broadcast packet. The HELLO information will be sent directly to the gateways listed in the ``sourcehellogateways'' option described below. qqqquuuuiiiieeeetttt Process all incoming HELLO packets, but do not supply any HELLO information despite the number of network interfaces present. ggggaaaatttteeeewwwwaaaayyyy # Process all incoming HELLO packets, supply HELLO information every fifteen seconds, and announce the default route (0.0.0.0) with a time delay of #. The time delay should be specified in milliseconds. The default route is only announced when actively peering with at least one of EGP neighbor, therefore should only be used when running EGP. If no ``HELLO'' clause is specified, HELLO will not be performed. EEEEGGGGPPPP {{{{yyyyeeeessss |||| nnnnoooo}}}} This clause allows the processing of EGP by _g_a_t_e_d to be turned on or off. nnnnoooo Do not perform any EGP processing. yyyyeeeessss Perform all EGP operations. Please note that by default, EGP processing will take place. Therefore, if no ``EGP'' clause is specified, all EGP operations will take place. aaaauuuuttttoooonnnnoooommmmoooouuuussssssssyyyysssstttteeeemmmm #### If performing the EGP protocol, this clause must be used to specify the autonomous system number (#). If not specified, _g_a_t_e_d will exit and give a fatal error message. eeeeggggppppmmmmaaaaxxxxaaaaccccqqqquuuuiiiirrrreeee #### If performing the EGP protocol, this clause specifies the number of EGP peers with whom _g_a_t_e_d will be performing EGP. This number must be greater than zero and less than or equal to the number of EGP neighbors specified or _g_a_t_e_d will exit. If this clause is omitted, all EGP neighbors will be acquired. eeeeggggppppnnnneeeeiiiigggghhhhbbbboooorrrr ggggaaaatttteeeewwwwaaaayyyy mmmmeeeettttrrrriiiicccciiiinnnn mmmmeeeettttrrrriiiicccc eeeeggggppppmmmmeeeettttrrrriiiiccccoooouuuutttt eeeeggggppppmmmmeeeettttrrrriiiicccc AAAASSSSiiiinnnn aaaassssiiiinnnn AAAASSSSoooouuuutttt aaaassssoooouuuutttt AAAASSSS aaaassss nnnnooooggggeeeennnnddddeeeeffffaaaauuuulllltttt aaaacccccccceeeeppppttttddddeeeeffffaaaauuuulllltttt PPPPaaaaggggeeee 5555 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) ddddeeeeffffaaaauuuullllttttoooouuuutttt eeeeggggppppmmmmeeeettttrrrriiiicccc vvvvaaaalllliiiiddddaaaatttteeee iiiinnnnttttffff iiiinnnntttteeeerrrrffffaaaacccceeee ssssoooouuuurrrrcccceeeennnneeeetttt nnnneeeetttt ggggaaaatttteeeewwwwaaaayyyy ggggaaaatttteeeewwwwaaaayyyy If performing the EGP protocol, this clause specifies with whom _g_a_t_e_d will be performing EGP. ``Gateway'' can be either a symbolic name in /_e_t_c/_h_o_s_t_s or an IP hostname in Internet dot (a.b.c.d) notation. Dot notation is recommended to avoid confusion. Each EGP neighbor will be acquired in the order listed in the configuration file. The ``metricin'' option is used to specify the internal time delay to be used as a metric for all of the routes learned from this neighbor. It should be specified as a time delay from zero to 30000. If this option and the validate option are not used, the internal metric used is the EGP distance multiplied by 100. The ``egpmetricout'' option is used to specify the EGP distance used for all nets advertised to this neighbor. It should be specified as an EGP distance in the range of 0 to 255. If this option is not specified, the internal time delay for each route will be converted to an EGP distance by division by 100 with distances greater than 255 being set to 255. The ``ASin'' option is used to verify the autonomous system number of this neighbor. If the autonomous system number specified in neighbor acquisition packets does not verify an error message is generated refusing the connection. If this option is not specified, no verification of autonomous system numbers is done. The ``ASout'' option is used to specify the autonomous system number in EGP packets sent to this neighbor. If not specified, the autonomous system specified in the ``autonomoussystem'' clause is used. This clause should not normally be used, it is reserved for a special situation interfacing between the ARPAnet and NSFnet. The ``AS'' option is used to specify that autonomous system number that will be assigned to routes learned from this neighbor. If not specified, the autonomous system used in the EGP packets received from this neighbor will be used. This clause should not normally be used, it is reserved for a special situation interfacing between the ARPAnet and NSFnet. The ``nogendefault'' option is used to specify this neighbor should not be considered for the internal generation of default when ``RIP gateway'' or ``HELLO gateway'' is used. If not specified, the internal default will be generated when actively peering with this neighbor. The ``acceptdefault'' option is used to specify that the default route (net 0.0.0.0) should be considered valid when received from this neighbor. If this option is not specified, the reception of the default route will cause a warning message to be printed and the route to be ignored. PPPPaaaaggggeeee 6666 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) The ``defaultout'' option is used to specify that the internally generated default may be passed to this EGP neighbor at the specified distance. The distance should be specified as an EGP distance from 0 to 255. A default route learned from another gateway will not be propagated to an EGP neighbor. Normally, no default route will be passed via EGP. The ``acceptdefault'' option should not be specified when the ``defaultout'' option is used. The egpmetric specified in the ``egpmetricout'' option does not apply, the default route will always use the metric specified by the ``defaultout'' option. The ``validate'' option is used to specify that all networks received from this EGP neighbor must be specified in ``validAS'' clause that also specifies the autonomous system of this neighbor. Networks not having a ``validAS'' clause will be ignored after a warning message is printed. The ``intf'' option is used to specify the interface used to send EGP packets to this neighbor. This option is only required when there is no common net/subnet with this egpneighbor. This option currently is only present for testing purposes and does not imply correct operation when peering with an egpneighbor that does not share a common net/subnet. The ``sourcenet'' option is used to specify the source network to be specified in EGP poll packets sent to this neighbor. If this option is not specified, the network (not subnet) of the interface used to communicate with this neighbor is used. This option is currently only present for testing purposes and does not imply correct operation when used. The ``gateway'' option is used to specify the gateway to be used when installing routes learned from an EGP neighbor on a different network. Normally these routes would be ignored. This option is currently only present for testing purposes and correct operation can not be assured when it is used. CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE OOOOPPPPTTTTIIIIOOOONNNNSSSS FFFFOOOORRRR HHHHAAAANNNNDDDDLLLLIIIINNNNGGGG RRRROOOOUUUUTTTTIIIINNNNGGGG IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN The following configuration file options tell _g_a_t_e_d how to deal with both incoming and outgoing routing information. ttttrrrruuuusssstttteeeeddddrrrriiiippppggggaaaatttteeeewwwwaaaayyyyssss ggggaaaatttteeeewwwwaaaayyyy [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] .................... ttttrrrruuuusssstttteeeeddddhhhheeeellllllllooooggggaaaatttteeeewwwwaaaayyyyssss ggggaaaatttteeeewwwwaaaayyyy [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] .................... When these clauses are specified, _g_a_t_e_d will only listen to RIP or HELLO information, respectively from these RIP or HELLO gateways. ``gateway'' can be either a symbolic name from /_e_t_c/_h_o_s_t_s or an IP host address in dot notation (a.b.c.d). Again, dot notation is recommended to eliminate confusion. Please note that the propagation of routing information is not restricted by this clause. ssssoooouuuurrrrcccceeeerrrriiiippppggggaaaatttteeeewwwwaaaayyyyssss ggggaaaatttteeeewwwwaaaayyyy [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] .................... ssssoooouuuurrrrcccceeeehhhheeeellllllllooooggggaaaatttteeeewwwwaaaayyyyssss ggggaaaatttteeeewwwwaaaayyyy [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] [[[[ggggaaaatttteeeewwwwaaaayyyy]]]] .................... PPPPaaaaggggeeee 7777 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) _G_a_t_e_d will send RIP or HELLO information directly to the gateways specified. If ``pointopoint'' is specified in the ``RIP'' or ``HELLO'' clauses mentioned above, _g_a_t_e_d will only send RIP or HELLO information to the specified gateways. _G_a_t_e_d will NOT send out any information using the broadcast address. If ``pointopoint'' is not specified in those clauses and _g_a_t_e_d is supplying of RIP or HELLO information, _g_a_t_e_d will send information to the specified gateways as well as broadcasting it using a broadcast address. nnnnoooorrrriiiippppoooouuuuttttiiiinnnntttteeeerrrrffffaaaacccceeee iiiinnnnttttffffaaaaddddddddrrrr [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] .................... nnnnoooohhhheeeelllllllloooooooouuuuttttiiiinnnntttteeeerrrrffffaaaacccceeee iiiinnnnttttffffaaaaddddddddrrrr [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] .................... nnnnoooorrrriiiippppffffrrrroooommmmiiiinnnntttteeeerrrrffffaaaacccceeee iiiinnnnttttffffaaaaddddddddrrrr [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] .................... nnnnoooohhhheeeellllllllooooffffrrrroooommmmiiiinnnntttteeeerrrrffffaaaacccceeee iiiinnnnttttffffaaaaddddddddrrrr [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] .................... The above clauses turn protocols on and off on a per interface basis. ``no{rip|hello}frominterface'' means that no RIP or HELLO information will be accepted coming into the listed interfaces from another gateway. ``no{rip|hello}outinterface'' means that no RIP or HELLO knowledge will be sent out of the listed interfaces. ``intfaddr'' should be in dot notation (a.b.c.d). ppppaaaassssssssiiiivvvveeeeiiiinnnntttteeeerrrrffffaaaacccceeeessss iiiinnnnttttffffaaaaddddddddrrrr [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] [[[[iiiinnnnttttffffaaaaddddddddrrrr]]]] .................... In order to dynamically determine if an interface is properly functioning, _g_a_t_e_d will time out an interface when no RIP, HELLO or EGP packets are being received on that particular interface. PSN interfaces send a RIP or HELLO packet to themselves to determine if the interface is properly functioning as the delay between EGP packets may be longer than the interface timeout. Interfaces that have timed out automatically have their routes re-installed when routing information is again received over the interface. The above clause stops _g_a_t_e_d from timing out the listed interfaces. The interfaces listed will always be considered up and working. If _g_a_t_e_d is not a RIP or HELLO supplier, all interfaces will not be aged and the ``passiveinterfaces'' automatically applies to all interfaces. iiiinnnntttteeeerrrrffffaaaacccceeeemmmmeeeettttrrrriiiicccc iiiinnnnttttffffaaaaddddddddrrrr mmmmeeeettttrrrriiiicccc#### This feature allows the specification of an interface metric for the listed interface. On systems that support interface metrics, this clause will override the kernel's metric. On systems that do not have support for an interface metric, this feature allows the specification of one. The interface metric is added to the true metric of each route that comes in via routing information from the listed interface. The interface metric is also added to the true metric of any information sent out via the listed interface. The metric of directly attached interfaces is also set to the interface metric, routing information broadcast about directly attached nets will be based on the interface metric specified. This clause is required for each interface on which an interface metric is desired. PPPPaaaaggggeeee 8888 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) rrrreeeeccccoooonnnnssssttttmmmmeeeettttrrrriiiicccc iiiinnnnttttffffaaaaddddddddrrrr mmmmeeeettttrrrriiiicccc#### This is a first attempt to throw hooks for fallback routing into _g_a_t_e_d. If the above clause is used, the metrics of the routes contained in any RIP information coming into the listed interface will be set to the specified ``metric#''. Metric reconstitution should not be used lightly, since it could be a major contributor in the formation of routing loops. UUUUSSSSEEEE TTTTHHHHIIIISSSS WWWWIIIITTTTHHHH EEEEXXXXTTTTRRRREEEEMMMMEEEE CCCCAAAAUUUUTTTTIIIIOOOONNNN.... Any route that has a metric of infinity will not be reconstituted and left as infinity. ffffiiiixxxxeeeeddddmmmmeeeettttrrrriiiicccc iiiinnnnttttffffaaaaddddddddrrrr pppprrrroooottttoooo {{{{rrrriiiipppp||||hhhheeeelllllllloooo}}}} mmmmeeeettttrrrriiiicccc#### This is another attempt to throw hooks for fallback routing into _g_a_t_e_d. If the above clause is used, all routing information sent out the specified interface will have a metric of ``metric#''. For RIP, specify the metric as a RIP hopcount from 0 to infinity. For HELLO, specify the metric as a HELLO delay in milliseconds from 0 to infinity. Any route that has a metric of infinity will be left as infinity. Fixed metrics should also be UUUUSSSSEEEEDDDD WWWWIIIITTTTHHHH EEEEXXXXTTTTRRRREEEEMMMMEEEE CCCCAAAAUUUUTTTTIIIIOOOONNNN!!!! ddddoooonnnnoooottttlllliiiisssstttteeeennnn nnnneeeetttt iiiinnnnttttffff aaaaddddddddrrrr [[[[aaaaddddddddrrrr]]]] ............ pppprrrroooottttoooo {{{{rrrriiiipppp||||hhhheeeelllllllloooo}}}} ddddoooonnnnoooottttlllliiiisssstttteeeennnnhhhhoooosssstttt hhhhoooosssstttt iiiinnnnttttffff aaaaddddddddrrrr [[[[aaaaddddddddrrrr]]]] ............ pppprrrroooottttoooo {{{{rrrriiiipppp||||hhhheeeelllllllloooo}}}} This clause reads as follows: keyword ``donotlisten'' followed by a network number, which should be in dot notation followed by keyword ``intf''. Then a list of interfaces in dot notation precede the keyword ``proto'', followed by ``rip'' or ``hello''. This means that any information regarding ``net'' coming in via the specified protocols AND from the specified interfaces will be ignored. The keyword ``all'' may be used after the keyword ``intf'' to specify all interfaces on the machine. For example: donotlisten 10.0.0.0 intf 128.84.253.200 proto rip means that any RIP information about net 10.0.0.0 coming in via interface 128.84.253.200 will be ignored. One clause is required for each net on which this restriction is desired. donotlisten 26.0.0.0 intf all proto rip hello means that any RIP and HELLO information about net 26.0.0.0 coming in via any interface will be ignored. ``donotlistenhost'' can be described the same way as above except that a host address is provided instead of a network address. Restrictions of the nature described above are applied to the specified host route learned of by the specified routing protocol. lllliiiisssstttteeeennnn nnnneeeetttt ggggaaaatttteeeewwwwaaaayyyy aaaaddddddddrrrr [[[[aaaaddddddddrrrr]]]] ............ pppprrrroooottttoooo {{{{rrrriiiipppp||||hhhheeeelllllllloooo}}}} lllliiiisssstttteeeennnnhhhhoooosssstttt hhhhoooosssstttt ggggaaaatttteeeewwwwaaaayyyy aaaaddddddddrrrr [[[[aaaaddddddddrrrr]]]] ............ pppprrrroooottttoooo {{{{rrrriiiipppp||||hhhheeeelllllllloooo}}}} PPPPaaaaggggeeee 9999 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) This clause reads as follows: keyword ``listen'' followed by a network number which should be in dot notation followed by keyword ``gateway''. Then a list of gateways in dot notation should precede the keyword ``proto'', followed by ``rip'' or ``hello''. This means to only listen to information about network ``net'' by the specified protocol(s) only from the listed ``gateways''. For example: listen 128.84.0.0 gateway 128.84.253.3 proto hello means that any HELLO information about net 128.84 coming in via gateway 128.84.253.3 will be accepted. Any other information about 128.84 from any other gateway will be rejected. One clause is necessary for each net to be restricted. listenhost 26.0.0.15 gateway 128.84.253.3 proto rip means that any information about host 26.0.0.15 must come via RIP and from gateway 128.84.253.3. All other information regarding this host will be ignored. aaaannnnnnnnoooouuuunnnncccceeee nnnneeeetttt iiiinnnnttttffff aaaaddddddddrrrr [[[[aaaaddddddddrrrr]]]] ............ pppprrrroooottttoooo ttttyyyyppppeeee [[[[eeeeggggppppmmmmeeeettttrrrriiiicccc ####]]]] aaaannnnnnnnoooouuuunnnncccceeeehhhhoooosssstttt hhhhoooosssstttt iiiinnnnttttffff aaaaddddddddrrrr ............ pppprrrroooottttoooo ttttyyyyppppeeee [[[[eeeeggggppppmmmmeeeettttrrrriiiicccc ####]]]] nnnnooooaaaannnnnnnnoooouuuunnnncccceeee nnnneeeetttt iiiinnnnttttffff aaaaddddddddrrrr [[[[aaaaddddddddrrrr]]]] ............ pppprrrroooottttoooo ttttyyyyppppeeee [[[[eeeeggggppppmmmmeeeettttrrrriiiicccc ####]]]] nnnnooooaaaannnnnnnnoooouuuunnnncccceeeehhhhoooosssstttt hhhhoooosssstttt iiiinnnnttttffff aaaaddddddddrrrr ............ pppprrrroooottttoooo ttttyyyyppppeeee [[[[eeeeggggppppmmmmeeeettttrrrriiiicccc ####]]]] These clauses allow restriction of the networks and hosts announced and by which protocol. The ``announce{host}'' and ``noannounce{host}'' clauses may not be used together on the same interface. With the ``announce{host}'' clause, _g_a_t_e_d will only announce the nets or hosts that have an associated ``announce{host}'' clause with the appropriate protocol. With the ``noannounce{host}'' clause, _g_a_t_e_d will announce everything, EXCEPT those nets or hosts that have an associated ``noannounce{host}'' clause. This allows a choice of announcing only what is on the announce list or everything except those nets on the noannounce list on a per interface basis. The arguments are the same as in the ``donotlisten'' clause except ``egp'' may be specified in the ``proto'' field. ``type'' can either be ``rip'', ``hello'', ``egp'', or any combination of the three. When ``egp'' is specified in the ``proto'' field, an egp metric must be specified. This is the metric at which _g_a_t_e_d will announce the listed net via EGP. Please note that these are not static route entries. These restrictions will only apply if the net or host is learned via one of the routing protocols. If a restricted network suddenly becomes unreachable and goes away, announcement of this net will stop until it is learned again. Currently, only one ``announce{host}'' or ``noannounce{host}'' may be specified per network or host. It is not possible to announce a network or host via HELLO out one interface and via RIP out another. PPPPaaaaggggeeee 11110000 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) Some examples: announce 128.84 intf all proto rip hello egp egpmetric 0 announce 10.0.0.0 intf all proto rip announce 0.0.0.0 intf 128.84.253.200 proto rip announce 35.0.0.0 intf all proto rip egp egpmetric 3 With only these four ``announce'' clauses in the configuration file, _g_a_t_e_d will only announce these four nets. It will announce 128.84.0.0 via RIP and HELLO to all interfaces and announce it via EGP with a metric of 0. Net 10.0.0.0 will be announced via RIP to all interfaces. Net 0.0.0.0 (default) will be announced by RIP out interface 128.84.253.200 only. Net 35.0.0.0 will be announced via RIP to all interfaces and announced via EGP with a metric of 3. These are the only nets that will be broadcast by this gateway. Once the first ``announce'' clause is specified, only the nets with ``announce'' clauses will be broadcast; this includes local subnets. Once an ``announce{host}'' or ``noannounce{host}'' has an ``all'' specified after an ``intf'', that clause is applied globally and the option of having per interface restrictions is lost. If no routing announcement restrictions are desired, ``announce'' clauses should not be used. All information learned will then be propagated out. Please note that this has no affect on the information to which _g_a_t_e_d listens. Any net that does not have an ``announce'' clause is still added to the kernel routing tables, but it is not announced via any of the routing protocols. To stop nets from being added to the kernel the ``donotlisten'' clause may be used. announce 128.84 intf 128.59.2.1 proto rip noannounce 128.84 intf 128.59.1.1 proto rip The above clauses mean that on interface 128.59.2.1, only information about 128.84.0.0 will be announced via RIP, but on interface 128.59.1.1, all information will be announced, except 128.84.0.0 via RIP. noannounce 128.84 intf all proto rip hello egp egpmetric 0 noannounce 10.0.0.0 intf all proto hello These clauses mean that except for the two specified nets, all nets will be propagated. Specifically, net 128.84.0.0 will not be announced on any interface via any protocols. Knowledge of 128.84.0.0 is not sent anywhere. Net 10.0.0.0 will not be announced via HELLO to any interface. This also implies that net 10.0.0.0 will be announced to every interface via RIP. This net will also be broadcast via EGP with a metric specified in the ``defaultegpmetric'' clause. ddddeeeeffffaaaauuuulllltttteeeeggggppppmmmmeeeettttrrrriiiicccc #### This is a default EGP metric to use when there are no routing restrictions. Normally, with no routing restrictions, _g_a_t_e_d announces all networks learned via HELLO or RIP via EGP with this specified default EGP metric. If this clause is not used, the default EGP metric is set to 255, which would make any EGP advertised route of this nature be ignored. PPPPaaaaggggeeee 11111111 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) When there are no routing restrictions, any network with a direct interface is announced via EGP with a metric of 0. Note that this does not include subnets, but only the non-subnetted network. ddddeeeeffffaaaauuuullllttttggggaaaatttteeeewwwwaaaayyyy ggggaaaatttteeeewwwwaaaayyyy pppprrrroooottttoooo [[[[mmmmeeeettttrrrriiiicccc mmmmeeeettttrrrriiiicccc]]]] {{{{aaaaccccttttiiiivvvveeee||||ppppaaaassssssssiiiivvvveeee}}}} This default gateway is installed in the kernel routing tables during initialization and reinstalled whenever information about the default route is lost. This route is installed with the time delay equivalent of a RIP metric of 15 unless another metric is specified with the metric option. If `RIP gateway' or `HELLO gateway' are in use this default route is deleted when successfully peering with an EGP neighbor not specified for ``nogendefault''. An ``active'' default route will be overridden by any other default route learned via another routing protocol. A ``passive'' default route will only be overridden by a default route with a lower metric. An ``active'' default route will not be propagated in routing updates, a ``passive'' default route will be propagated. ``gateway'' should be an address in dot notation. ``metric'' is optional and should be a metric in the specified protocol between zero and infinity, if not specified a RIP metric of 15 is used. ``proto'' should be either ``rip'', ``egp'', or ``hello''. The ``proto'' field initializes the protocol by which the route was learned. Although in this case it is unused, but the field is remains for consistency. nnnneeeetttt nnnneeeettttaaaaddddddddrrrr ggggaaaatttteeeewwwwaaaayyyy aaaaddddddddrrrr mmmmeeeettttrrrriiiicccc hhhhooooppppccccnnnntttt {{{{rrrriiiipppp||||eeeeggggpppp||||hhhheeeelllllllloooo}}}} hhhhoooosssstttt hhhhoooossssttttaaaaddddddddrrrr ggggaaaatttteeeewwwwaaaayyyy aaaaddddddddrrrr mmmmeeeettttrrrriiiicccc hhhhooooppppccccnnnntttt {{{{rrrriiiipppp||||eeeeggggpppp||||hhhheeeelllllllloooo}}}} The following clauses install a static route to net ``netaddr'' or host ``hostaddr'' through gateway ``addr'' at a metric of ``hopcnt'' learned via either RIP, HELLO, or EGP. As usual, dot notation is recommended for the addresses. This route will be installed in the kernel's routing table and will never be affected by any other gateway's RIP or HELLO announcements. The protocol by which it was learned is important if the route is to be announced via EGP. If the protocol is ``rip'' or ``hello'' and there are no routing restrictions, then this route will be announced by EGP with a metric of ``defaultegpmetric''. If the protocol is ``egp'' and there are no routing restrictions, then this route will be announced by EGP with a metric of ``hopcnt''. eeeeggggppppnnnneeeettttssssrrrreeeeaaaacccchhhhaaaabbbblllleeee nnnneeeetttt [[[[nnnneeeetttt]]]] [[[[nnnneeeetttt]]]] .................... This option was left in as a ``soft restriction''. It cannot be used when the ``announce'' or ``noannounce'' clauses are used. Normally, with no restrictions, _g_a_t_e_d announces all routes learned from RIP and HELLO via EGP. The ``egpnetsreachable'' clause restricts EGP announcement to those nets listed in the clause. The metric used for the HELLO and RIP PPPPaaaaggggeeee 11112222 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) learned routes is the value given in the ``defaultegpmetric'' clause. If this clause does not specify a value, the value is set to 255. With the ``egpnetsreachable'' clause, individual unique EGP metrics may not be set for each net. The ``defaultegpmetric'' is used for all networks except those that are directly connected, which use a metric of 0. mmmmaaaarrrrttttiiiiaaaannnnnnnneeeettttssss nnnneeeetttt [[[[nnnneeeetttt]]]] [[[[nnnneeeetttt]]]] ............ This clause appends to _g_a_t_e_d'_s list of ``martian'' networks. ``Martian'' networks are those known to be invalid and should be ignored. When _g_a_t_e_d hears about one of these networks through any means, it will immediately ignore it. If ``external'' tracing is enabled, a message will be printed to the trace log. Multiple occurrences of the ``martiannets'' clause accumulate. An initial list of ``martian'' networks is coded into gated. This list contains 127.0.0.0, 128.0.0.0, 191.253.0.0, 192.0.0.0, 223.255.255.0, and 224.0.0.0. CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE OOOOPPPPTTTTIIIIOOOONNNNSSSS FFFFOOOORRRR AAAAUUUUTTTTOOOONNNNOOOOMMMMOOOOUUUUSSSS SSSSYYYYSSSSTTTTEEEEMMMM RRRROOOOUUUUTTTTIIIINNNNGGGG In the internal routing tables, _g_a_t_e_d maintains the autonomous system number from which each route was learned. Autonomous systems are used only when an exterior routing protocol is in use, in this case EGP. Routes are tagged with the autonomous system number of the EGP peer from which they were learned. Routes learned via the interior routing protocols, RIP and HELLO, are tagged with the autonomous system number specified in the ``autonomoussystem'' clause. _G_a_t_e_d normally does not propagate routes learned from exterior routing protocols to interior routing protocols. Historically this is because of the ARPANET core EGP speakers which do not have adequate validation of routing information they receive. Some of the following clauses allow exterior routes to be propagated via interior protocols. Therefore it is imperative that utmost care be taken when allowing the propagation of exterior routes. The following clauses provide limited control over routing based on autonomous system number. vvvvaaaalllliiiiddddAAAASSSS nnnneeeetttt AAAASSSS aaaassss mmmmeeeettttrrrriiiicccc mmmmeeeettttrrrriiiicccc The ``validAS'' clause is used for validation of networks from certain AS. When an EGP update is received from a neighbor which has the ``validate'' option specified on the associated ``egpneighbor'' clause a ``validAS'' clause is searched for specifying that network and the autonomous system number of the EGP neighbor. If the appropriate ``validAS'' clause is located, the network is considered for addition to the routing table with the specified metric. If a ``validAS'' clause is not located, a warning message is printed and the network is ignored. PPPPaaaaggggeeee 11113333 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) A network may be specified in several ``validAS'' clauses as being associated with several different autonomous systems. aaaannnnnnnnoooouuuunnnncccceeeettttooooAAAASSSS aaaassss0000 {{{{rrrreeeessssttttrrrriiiicccctttt||||nnnnoooorrrreeeessssttttrrrriiiicccctttt}}}} AAAASSSSlllliiiisssstttt aaaassss1111 aaaassss2222 aaaassss3333 ............ nnnnooooaaaannnnnnnnoooouuuunnnncccceeeettttooooAAAASSSS aaaassss0000 {{{{rrrreeeessssttttrrrriiiicccctttt||||nnnnoooorrrreeeessssttttrrrriiiicccctttt}}}} AAAASSSSlllliiiisssstttt aaaassss1111 aaaassss2222 aaaassss3333 ............ The ``announcetoAS'' and ``noannouncetoAS'' control the exchanging of routing information between different autonomous systems. Normally _g_a_t_e_d will not propagate routing information between autonomous systems. The exception to this is that routes learned from _g_a_t_e_d's own autonomous system via RIP and HELLO will be propagated via EGP. These clauses allow information learned via EGP from one autonomous system to be propagated via EGP to another autonomous system or via RIP and HELLO to _g_a_t_e_d's own autonomous system. If the ``announcetoAS'' clause is specified, information learned via EGP from autonomous systems _a_s_1, _a_s_2, _a_s_3, ... will be propagated to autonomous system _a_s_0. If _g_a_t_e_d's own autonomous system, as specified in the ``autonomoussystem'' clause, is specified as _a_s_0, this information will be propagated via RIP and HELLO. Routing information from autonomous systems not specified in the ASlist will not be propagated to autonomous system _a_s_0. If the ``noannouncetoAS'' clause is specified, information learned via EGP from all autonomous systems except _a_s_1, _a_s_2, _a_s_3, ... will be propagated to autonomous systems _a_s_0. If _g_a_t_e_d's own autonomous system is specified as _a_s_0, this information will not be propagated via RIP and HELLO. The ``[no]restrict'' option controls the application of ``announce'' and ``noannounce'' clauses to the propagation of routes to different autonomous systems. If ``restrict'' is specified, normal announcement restrictions do apply, if ``norestrict'' is specified, announcement restrictions are not considered, all routes from the source autonomous systems are propagated to the destination autonomous system. Only one ``announcetoAS'' or ``noannounceAS'' clause may be specified per target autonomous system. NNNNOOOOTTTTEEEESSSS OOOONNNN CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN OOOOPPPPTTTTIIIIOOOONNNNSSSS If EGP is being used when supplying the default route (via ``RIP gateway'' or ``HELLO gateway'') and all EGP neighbors are lost, the default route will not be advertised until at least one EGP neighbor is regained. With the complexity of the current network topology and with many back- door paths to networks, the use of routing restrictions is recommended. With the current routing strategies, it is easy for illegal or invalid networks to penetrate into the ARPAnet Core or the NSFnet backbone. Using routing restrictions does take a little more maintenance time and routing restrictions are not the long term answer, but, for now, in order to be good Internet players, we must use them. PPPPaaaaggggeeee 11114444 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD IIIINNNNTTTTEEEERRRRNNNNAAAALLLL MMMMEEEETTTTRRRRIIIICCCCSSSS _G_a_t_e_d stores all metrics internally as a time delay in milliseconds to preserve the granularity of HELLO time delays. The internal delay ranges from 0 to 30000 milliseconds with 30000 representing infinity. Metrics from other protocols are translated to and from a time delay as they are received and transmitted. EGP distances are not comparable to HELLO and RIP metrics but are stored as a time delay internally for comparison with other EGP metrics. The conversion factor between EGP distances and time delays is 100. RIP and interface metrics are translated to and from the internal time delays with the use of the following translation tables: Time Delay RIP metric RIP metric Time Delay 0 - 0 0 0 0 1 - 100 1 1 100 101 - 148 2 2 148 149 - 219 3 3 219 220 - 325 4 4 325 326 - 481 5 5 481 482 - 713 6 6 713 714 - 1057 7 7 1057 1058 - 1567 8 8 1567 1568 - 2322 9 9 2322 2323 - 3440 10 10 3440 3441 - 5097 11 11 5097 5098 - 7552 12 12 7552 7553 - 11190 13 13 11190 11191 - 16579 14 14 16579 16580 - 24564 15 15 24564 24565 - 30000 16 16 30000 NNNNOOOOTTTTEEEESSSS OOOONNNN IIIIMMMMPPPPLLLLEEEEMMMMEEEENNNNTTTTAAAATTTTIIIIOOOONNNN SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCSSSS In the _g_a_t_e_d configuration file, all references to POINT-TO-POINT interfaces must use the DESTINATION address. All protocols have a two minute hold down. When a routing update indicates that the route in use is being deleted, _g_a_t_e_d will not delete the route for two minutes. Changes can be made to the interfaces and _g_a_t_e_d will notice them without having to restart the process. If the netmask, subnetmask, broadcast address, or interface metric are changed, the interface should be marked down with _i_f_c_o_n_f_i_g(1M), then marked up at least thirty seconds later. Flag changes do not require the interface to be brought down and back up. RIP propagates and listens to host routes, thus allowing the consistent handling of PTP links. The RIP_TRACE commands are also supported. Subnet interfaces are supported. Subnet information will only be propagated on interfaces to other subnets of the same network. For example, if there is a gateway between two class B networks, the subnet routes for each respective class B net are not propagated into the other class B net. Just the class B network number is propagated. PPPPaaaaggggeeee 11115555 GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) GGGGAAAATTTTEEEEDDDD((((1111MMMM)))) _G_a_t_e_d listens to host and network REDIRECTs and tries to take an action on the REDIRECT for its own internal tables that parallels the kernel's action. In this way, the redirect routine in _g_a_t_e_d parallels the Berkeley kernel redirect routine as closely as possible. Unlike the Berkeley kernel, _g_a_t_e_d times out routes learned via a REDIRECT after six minutes. The route is then deleted from the kernel routing tables. This helps keep the routing tables more consistent. Any route that was learned via a REDIRECT is NOT announced by any routing protocol. The _g_a_t_e_d EGP code verifies that all nets sent and received are valid class A, B or C networks per the EGP specification. Information about networks that do not meet these criteria is not propagated. If an EGP update packet contains information about a network that is not either class A, B or C, the update is considered to be in error and is ignored. FFFFIIIILLLLEEEESSSS ////uuuussssrrrr////eeeettttcccc////ggggaaaatttteeeedddd....ccccoooonnnnffff configuration file. ////uuuussssrrrr////ttttmmmmpppp////ggggaaaatttteeeedddd____dddduuuummmmpppp memory dump file ////uuuussssrrrr////eeeettttcccc////ggggaaaatttteeeedddd _g_a_t_e_d itself SSSSEEEEEEEE AAAALLLLSSSSOOOO _r_o_u_t_e_d(1M) RFC827 EXTERIOR GATEWAY PROTOCOL (EGP) RFC888 "STUB" EXTERIOR GATEWAY PROTOCOL RFC891 DCN Local-Network Protocols (HELLO) RFC904 Exterior Gateway Protocol Formal Specification RFC911 EGP GATEWAY UNDER BERKELEY UNIX 4.2 CCCCRRRREEEEDDDDIIIITTTTSSSS This program was derived from Paul Kirton's EGP for UNIX, UC at Berkeley's _r_o_u_t_e_d(1M), and HELLO routines by Mike Petry at the University of Maryland. PPPPaaaaggggeeee 11116666